double-click on a network cloud to do an Edit:Reveal physical layer (if you've used Edit:Cloudness… to define the cloud's RMON matrixSDIndex);
double-click on anything else to do an Edit:Show details
note that SMAP can only fetch one table at a time from any given device; while SMAP is getting a table from a device it will fuzz out the device's icon(s), and if you double-click on one of those fuzzed-out icons, SMAP will just beep at you.
the first time an RMON Matrix egg is displayed, it'll include every device known to the matrix and it'll probably be unviewably overdetailed. don't panic: after the first polling interval, when the agent is repolled and its egg is redisplayed, the devices with insignicant traffic volumes will disappear and the display ought to be a lot more readable. if you find there are still too many devices in the display, adjust Settings:Etc:RMON Matrix min avg BPS… to make the lower-traffic devices disappear. Finally, don't be surprised if SMAP takes a long time to refresh your RMON matrix displays, especially if a slow serial link is involved - those matrix tables can be huge, and they can only be fetched one row at a time. To improve this speed [at the expense of other processes running on the same Mac] you might try increasing the value of Settings:Etc:Selfishness… .
if you're running SMAP on a slow Mac and you need to improve its performance, try turning off DNS Device name and MIB object name logging via the Log submenu, or try turning off all logging.
normally SMAP gathers logical network info from a mapped device only once, the first time it appears in a map. If you make network topology changes while SMAP's running, SMAP will probably not notice them till you close and reopen the appropriate map windows.
interface activity is shown on each side of the core of each interface/cloud connector,flowing clockwise:
- so if you've got a horizontal connector, the thickness & colour of the bar on the upper side of the connector are for traffic travelling to the right, the underside is for the opposite direction
- or to put it another way, if a device interface is above and its cloud is below, traffic out of the interface will appear on the right side of the connector, and its inbound traffic will appear on the left
a device will go red when it doesn't respond to SMAP's SNMP polling;
its label will go red when it doesn't respond to SMAP's ICMP pinging;
the core of an interface connector goes red when the interface is down,
but red along the side of a connector signifies input or output error rates above your threshold.
if you see red along the side of an interface connector, and you're not sure why: double-click on the connector, or do an Edit:Show details on it, and inspect the displayed values for ifInDiscards, ifInErrors, ifInUnknownProtos, ifOutDiscards, and ifOutErrors
SMAP can't do much about broken SNMP agents - for example, the old v1 SunOS SNMP daemon from CMU doesn't return certain useful things like interface speed and type. The original NetWare 3.11 SNMP agent is similarly deficient. And the HP-UX v9 snmpd violates RFC1213: it doesn't know about the last couple of columns of ipRouteEntry. And the NAT EtherMeter seems to randomly sprinkle nonsensical values in its output.
frame relay interfaces won't be shown connected to their logical networks; one physical interface may have many logical PVCs associated with it, but there's no common manufacturer-independent way yet of measuring traffic on these circuits or subinterfaces. Instead, you'll see at most one frame relay cloud for each physical interface, with the display showing you the total activity on the frame access line. Same for x.25 SVCs, I suppose, if anyone out there still does x.25.
depending on how your MacTCP is configured, or if you're using Open Transport, the router discovery process may need to ask you for the IP address of a known router, to get the discovery started
the datagram logbuffer size is subject only to the maximum application memory you've set in the application's Finder:File:Get Info window
but the monitor windows are limited to showing you the last 32K bytes of the datagram log
an insert of 'all interesting interfaces' on a device will ignore interfaces which have the same [non-null] physical address as lower-numbered interfaces - some devices maintain these redundant interface entries for their convenience, but we usually don't want them cluttering up our maps
sorry about the clumsy screen refreshes you sometimes see when SMAP has to update a complicated map - they're an unfortunate consequence of a couple of internal MacOS QuickDraw limitations that would cause severe grief if SMAP were to simply request a redraw of the portions of the map that had changed since the last redraw
the items in the Map menu affect the current window, if it's a map; if the front window is not a map then the items change your global Map settings, which will be applied to any new map windows you create.
the Settings:Save settings and Settings:Reset settings commands refer to these global Map settings, along with whatever you get to specify in the rest of the Settings menu. There's currently no way to return a given window to its default settings.
about the Remove redundant devices command of the Settings:Etc submenu: normally you'll leave this turned on, since during a speedy device discovery, it's otherwise possible to get the same device appearing at several places in the same map. But there are certain circumstances, which I won't bother explaining, when this feature might misbehave and remove devices that you want kept. Turn this option off for such occasions.
Implementation limits on Cloudness settings:
* I've supplied useable defaults for whole-network RMON agents, for unswitched hubs that support the Repeater MIB, and for Networth hubs
* if that's not good enough, the relevant MIBs are brand-specific so it's up to you to figure out what object IDs to use when you Edit:Cloudness - if you can make this work for your particular brand of managed hub, great, let me know and I'll try to incorporate your findings into the next release of the program - if you can't make it work, sorry...
* the highest acceptable MIB table row number is 50
* and there's a limit of about 37 on the number of mib variables you can fetch in one query, which means that the min and max row numbers of your hub's stats queries can't be farther apart than this
* actually, these limits may be somewhat smaller in practice, since RFC1157 allows devices to ignore SNMP datagrams of more than 484 bytes
* but if your device MIB is well-designed this shouldn't be a problem. Per RFC1212: "As a rule of thumb, a conceptual row should contain no more than approximately 20 objects".
Some other implementation limits:
* if you've got more than 127 interfaces on a device, you'll only be able to see the first 127.
* don't bother trying to use a community name that contains a comma - SMAP won't allow it
Here's the tab-delimited log fields you get in SMAP datagram logbuffers and files, and in the Monitor windows:
>the source or destination address (an IP address or DNS name depending on Settings:Logging:Log DNS device names)
> [new] relative time: the number of ticks (60ths of a second) since your Mac was last started
>absolute time: the number of seconds between 1 Jan 1904 and the time the datagram was logged
>the date the datagram was logged
>the time the datagram was logged
>'i' or 'o' to show if the datagram was Input to or Output by SMAP, or 'X' for undecipherable inputs, or 'C' for communication errors, or 'N' if this response is missing objects we asked for, 'D' if a device has become unresponsive to polling, or 'U' if the device is once again pollable, or 'T' if a device has become unresponsive to pinging, or 'P' is the device is once again repingable
>a letter code to identify irregular GetNexts of various kinds (don't spend time figuring out which code means what, it'll probably change in the next release...), or a number to identify a scheduled Get on the given-numbered interface, or '!' for an SNMP trap, or '>' for a syslog text line
the rest of each line depends on whether the log entry is for a syslog or generic text message, an SNMP trap, or for some sort of Get or GetNext or SNMP response.
For syslog and generic text messages>>>
>the text of the message
For Gets and GetNexts and their responses>>>
>the id of the MIB object whose value is first in the following list
>a list of MIB object values starting with the indicated object and continuing down that object's column in the device MIB, so for example the value of ifOperStatus.12 (column 8 of ifEntry) would be followed by the value of ifLastChange.12 (column 9)
>but with Full-on debug logging, each MIB object value will be preceded by its object id
For SNMP traps>>>
>the trap type, as a text string
>the trap specific-code, often zero
>the number of ticks since the agent generating the trap started running
>an Enterprise object identifier
>the address of the agent generating the trap
>finally,whatever 'interesting' (object identifier, object value) pairs the agent decided to send along
[the following features are normally disabled…]
MIB knowledge:Learn a new MIB is a hack. It works just well enough to pick up the object names of the small number of RFC MIBs that are at SMAP's core. [This wasn't my plan - I had intended to implement a solid reliable interpreter based on the official ASN.1 standard, ISO 8824, but I ended up having to reverse-engineer and otherwise guess at the contents of this standard - the spec is not online anywhere - in electronic form it is only available by subscription from the ITU, and they charge sf3,200, or over cad$3700!] If you'd like to try installing your own private MIBS into SMAP's 'SMAP MIBs' document, okay, just hold down the option key and this command will be enabled. But here are some of the limitations:
* MIB parsing is very basic. the standard MIBs are handled ok, but if the person who wrote your MIB got at all creative with the ASN.1 syntax, the MIB learn is likely to fail.
* there are two real limitations with the hierarchical-menu approach used in the Edit:Browse command: (1) MacOS limits the total number of these submenus, so SMAP'll complain if you've defined more than a collective total of maybe 200 MIB tables [which is a small number, considering for example the 'interfaces' MIB alone amounts to three tables: interfaces, ifTable, and ifEntry]; (2) MacOS limits the maximum depth of these submenus, so depending on the design of your MIB you may not be able to Edit:Browse its lower levels.
* if a MIB is important to you and SMAP isn't able to parse it, send me a copy and I'll see if I can convince SMAP to learn it. No promises though.
* the only way to unlearn a MIB module is to do a ResEdit delete on its corresponding 'SMAP MIBs' smib resource
you have to be cautious with Discover:IP nodes using NetToMediaTable...it was provided for users with small networks.
Anyone else ought to avoid this command, since it can potentially add hundreds or thousands of nodes to your map, which could easily overpower your Mac, or your MacTCP, or your QuickDraw, or your patience. Okay, if you've read this far and you still want to try out node discovery, it's available, just hold down the Option key when you pull down the Discover menu. Just don't be too surprised if your screen fills with little boxes and connectors zanging randomly across the window.
you don't really want to use Discover:IP routers using ipForwardTable, it's just there for the future if MIB agents decide it's okay to stop supporting the currently-deprecated ipRouteTable. Doing ipForwardTable discovery at the same time as ipRouteTable discovery will just generate lots of redundant redundant network traffic.
Stick with ipRouteTable.
there are two reasons why IPX network-number discovery is not automatic:
* [1] cosmetic - some devices (including many NetWare 3.12 servers) when asked for their IPX MIB will refuse to respond, so SMAP will end up briefly taking those devices through a yellow warning to a red timeout error status before returning to normal - you may find this disconcerting, but there is no way for SMAP to distinguish this sort of agent reaction from a real SNMP timeout.
* [2] broken agents - when I first started testing this code, I discovered that one of my NetWare servers would crash when SMAP asked for a certain table in the Novell MIB. I can't blame SMAP for this - I duplicated this behaviour using a third-party MIB browser - obviously an SNMP agent that repeatedly crashes its device is badly broken. If you want to do IPX network discovery using SMAP or any other SNMP software, proceed cautiously - one of your NetWare servers may have a similar problem. (For the record, the server that crashed was running standard current-patch-level NetWare 3.12 and a copy of NetWare Connect that had been upgraded from v1 to v2. After seeing these crashes, I installed the current version of the 'IPXRTR' IPX routing upgrade, and loaded the NLSP-aware NLM that came with this package, and now I can query the server without crashing it.)
* So, if you'd still like to try IPX discovery, okay, consider yourself warned, you can use two related menu commands which are enabled only when you're holding down the Shift and Option keys: Settings:Etc:Autodiscover IPX , which determines whether or not a device's IPX MIB should be automatically discovered when it's first added to one of your maps, and Map:IPX, which will do a manual (re)discovery of the IPX network info for every device SMAP has been told about since it started up and revise the current map's view to include only IPX-related information.
